00100	Protocol sketch      for     a supra-SPOT concept formation program.
00200	
00300	U represents the user, S the system, in the following  dialog excerpts.
00400	
00500	S:	Hi.  What can I do for you?
00600	U: 	Write a concept formation program. Here is SPOT, which you have
00700		just written.  Get psyched up and we will begin adding to it.
00800	S:	OK, I am in a state of full awareness re the writing of SPOT.
00900		What would you like to do to it?
01000	U:	One thing, I notice that some of the transfers between the MAY,
01100		MUST, and MUSNT lists cause past examples to work improperly.
01200		Find me an example of this phenomenon.
01300	S:	If  we must choose between two features to transfer from MAY to
01400		MUST, only one is correct, we choose the incorrect one, later
01500		discover our mistake, put it back onto the MAY list.  Then that
01600		first example would again be misidentified.
01700	U:	Any other cases?
01800	S:	When we choose to move a feature from MAY to MUST, we might have
01900		already seen a scene in which it did NOT occur. So this would
02000		immediately cause the old scene to be misidentified. 
02100	U:	How could you fix this up?
02200	S:	(i) By keeping around all the old scenes, using them to check new
02300		changes. (ii) By tagging each MAY feature to indicate whether it
02400		has ever not appeared in this type of scene. (iii) By creating a
02500		fourth list, ALWAYS:WAS, to keep separate those MAY candidates
02600		which could reliably be transferred to MUST.
02700	U:	How would the last two ideas work?
02800	S:	When a concept is first encountered, no features are tagged. When a
02900		new instance is seen, all relations in the symmetric difference of
03000		the existing MAY set and the new set of relations is tagged.
03100		The next case is analogous, with tagging/notagging equivalent to
03200		position on the MAY/ALWAYS list.
03300	U:	Which is better?
03400	S:	(i) is the quickest but uses the most space, (ii) is most easily
03500		implemented and optimized, (iii) is easy to implement and the most
03600		symmetric. In view of future expansions, I suggest (iii).
03700	U:	OK, do it.
03800	S:	<sound of grinding, shredding, looping, etc. in the background> OK.
03900		What next?
04000	U:	I want a scene to be correctly identified even if its objects have
04100		new names. 
04200	S:	Unclear. Here is my idea of arch: (arch (a b c) (MUST (supports a c)
04300		(supports b c))  (MUSNT (touches a b)) (MAY (green a)(block c))).
04400		What kind of altered scene should be identified as an arch, now?
04500	U:	(? (x y z) (supports x z)(supports y z)(green x)(blue y))
04550	S:	I can see many ways to do this.   (i) We may examine and then use
04600	        the object list to determine a mapping which is applied to the rest
04700		of the scene.  (ii) All scenes are transformed into canonical form
04800		when read in, i.e., as if they had all had objects (a b c ...)
04900		Is one of these what you want?
05000	U:	Compare the two for me, please.
05200	S:	No, I don't want to.